home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / standards / CCITT / 1992 / X / x403_2.asc < prev    next >
Encoding:
Text File  |  1993-07-15  |  39.3 KB  |  1,775 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.          Annex A  Test Notation
  8.          
  9.          A.1  Introduction
  10.          
  11.          This annex is an integral part of this Recommendation and describes
  12.          the notation used in the test suite manuals.
  13.          
  14.          The test notation described here is based on the test notation
  15.          called Tree and Tabular Combined Notation (TTCN) that has been
  16.          developed jointly by ISO and CCITT.
  17.          
  18.          The notation described in this Recommendation is derived from an
  19.          early form of TTCN and has been developed specifically for use in
  20.          the MHS conformance testing specifications.
  21.          
  22.          Each of the MHS test suites is specified in five parts:
  23.          
  24.           -  Declaration Part
  25.           -  Dynamic Part
  26.           -  Constraints Part
  27.           -  Test Case Identification
  28.           -  Cross-References
  29.          
  30.          A.2  Declaration Part
  31.          
  32.          The Declaration Part declares the environment and objects used in
  33.          the test suites and is composed of 7 sections:
  34.          
  35.           -  Test Configurations
  36.           -  Test Suite Parameters (TSPs)
  37.           -  Service Access Points (SAPs)
  38.           -  Abstract Service Primitives (ASPs)
  39.           -  Protocol Data Units (PDUs)
  40.           -  Timers
  41.           -  Abbreviations
  42.          
  43.          A.2.1  Test Configurations
  44.          
  45.          The points of control and observation are declared in this section.
  46.          
  47.          A.2.2  Test Suite Parameters
  48.          
  49.          Every MHS Test Suite has a set of parameters whose values are fixed
  50.          prior to testing and which are used to define a specific testing
  51.          environment.
  52.          
  53.          TSPs are declared in tabular form as shown in Figure A-1/X.403.
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.          Figure A-1/X.403  Test Suite Parameters.
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.          
  78.          By convention the name of each Test Suite Parameter in the MHS test
  79.          suites is of the form:
  80.          
  81.                    TSP_<name>
  82.          
  83.          
  84.          A.2.3  Service Access Points (SAPs)
  85.          
  86.          Service Access Points are used as points of control and observation
  87.          in the MHS Test Suites and are declared in tabular form as shown in
  88.          Figure A-2/X.403.
  89.          
  90.                                                                     
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.          
  99.          Figure A-2/X.403  Service Access Points.
  100.          
  101.          
  102.          By convention the name of a SAP in the MHS Test Suites is generally
  103.          one capital letter, such as T, U, V (for tester SAPs) or I, J, K
  104.          (for IUT SAPs).
  105.          
  106.          A.2.4  Abstract Service Primitives
  107.          
  108.          Each ASP type and its associated parameters used in a test suite is
  109.          declared in tabular form as shown in Figure A-3/X.403.
  110.          
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.          
  120.          Figure A-3/X.403  Abstract Service Primitives.
  121.          
  122.          
  123.          The name of the ASP is specified in the "ASP" field and is derived
  124.          from the corresponding name in the X.400 Series of Recommendations.
  125.          The SAP at which the ASP occurs is specified in the "SAP" field.
  126.          The parameters of the ASP are declared in the "NAME" column
  127.          together with information in "RANGE OF VALUES OR TYPE", "COMMENTS"
  128.          and "Conditional/Mandatory" columns.
  129.          
  130.          Since there are no IPMS(P2) ASPs defined in the Recommendations, in
  131.          order to describe conformance tests it has been necessary to
  132.          construct hypothetical ASPs at the upper boundary of the User Agent
  133.          Layer. This does not imply, however that manufacturers are required
  134.          to implement these ASPs within their systems. It serves only to
  135.          formalize the requirements for observation and invocation of IPMS
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.          service elements by the use of these new ASPs. The relation between
  143.          IPMS service elements and the actual behaviour of the IUT has to be
  144.          specified in the implementation-dependent PIXIT.
  145.          
  146.          A.2.5  Protocol Data Units
  147.          
  148.          The PDU types used in test suites are declared in the form of
  149.          tables as shown in Figure A-4/X.403. These PDUs are not defined
  150.          explicitly in the test suite, but are given a precise reference to
  151.          the full definition in the X.400 Recommendations, in the type name
  152.          section of the table.
  153.          
  154.  
  155.  
  156.                                                                     
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.          
  164.          Figure A-4/X.403  Protocol Data Units.
  165.  
  166.          A.2.6  Timers
  167.          
  168.          This section declares the timers to be used. Timer values are
  169.          expressions in terms of Test Suite Parameters, and are fixed for
  170.          the whole test suite. Timer values are declared in tabular form as
  171.          shown in figure A-5/X.403.
  172.          
  173.                                                                     
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.          
  182.          Figure A-5/X.403  Timers.
  183.          
  184.          A.2.7  Abbreviations
  185.          
  186.          Abbreviations used in the Test Suite are defined in the form of a
  187.          table as shown in Figure A-6/X.403.
  188.          
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.          
  198.          Figure A-6/X.403  Abbreviations.
  199.          
  200.          
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.          A.3     Dynamic Part
  213.          
  214.          The Dynamic Part defines the test cases of a test suite in terms of
  215.          trees of behaviour.
  216.          
  217.          Sections A.3.1 and A.3.2 describe generally how trees of behaviour
  218.          are defined.
  219.          
  220.          Section A.3.3 describes the content and use of Defaults Library.
  221.          
  222.          Section A.3.4 describes the content and use of Test Step Library.
  223.          
  224.          Section A.3.5 describes how each test case in the main body of a
  225.          test suite is specified.
  226.  
  227.          A.3.1  Proforma table for Test Behaviours
  228.          
  229.                                                                     
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.          
  247.          Figure A-7/X.403  Behaviour Description.
  248.          
  249.          
  250.          <title> BEHAVIOUR:
  251.              
  252.              Title of the behaviour: DEFAULT for the Default Library;
  253.              DYNAMIC for the Test Step Library and test cases.
  254.          
  255.          IDENTIFIER:
  256.              
  257.              This provides a unique identifier for the behaviour
  258.              description.
  259.          
  260.          DEFAULTS:
  261.              
  262.              This lists the identifiers of default behaviour descriptions
  263.              which are to be used in conjunction with the Dynamic behaviour
  264.              shown in the "BEHAVIOUR DESCRIPTION" part.
  265.          
  266.          BEHAVIOUR DESCRIPTION:
  267.              
  268.              Test behaviour is defined using a tree notation as described
  269.              in A.3.2.
  270.          
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.          LABEL:
  278.              
  279.              The LABELS column may be used to identify events. Branches
  280.              between events (i.e. "GO TO") are specified by "   > Label" in
  281.              the behaviour tree.
  282.          
  283.          CONSTRAINTS REFERENCE:
  284.              
  285.              For each ASP event of a behaviour tree line, this column gives
  286.              the reference to the specific ASP value defined in the
  287.              Constraints Part.
  288.  
  289.          COMMENTS:
  290.              
  291.              This column provides comments which ease understanding of the
  292.              events. Additional comments may be given in the "Extended
  293.              Comments" area. This column can also be used to identify test
  294.              PDUs associated with test events.
  295.          
  296.          RESULT:
  297.              
  298.              This column indicates which test events generate test verdicts.
  299.              Values of test verdicts are:
  300.          
  301.              - pass:          no misbehaviour of the IUT is detected.
  302.              - fail:          misbehaviour of the IUT is detected.
  303.              - inconclusive:  the observed behaviour does not allow the
  304.                               assignment of a pass or fail verdict.
  305.          
  306.          A.3.2  Tree notation for test behaviours.
  307.          
  308.          Trees of behaviour are defined in terms of events which are
  309.          generally of the form
  310.          
  311.                   <SAP>!<event>
  312.          
  313.          or of the form
  314.          
  315.                   <SAP>?<event>
  316.          
  317.          The <SAP> is the point of control and observation at which the
  318.          <event> occurs. The SAPs used are those declared in the Declaration
  319.          Part.
  320.          
  321.          The "!" symbol indicates that the event is sent from the SAP and
  322.          "?" indicates that the event is received at the SAP.
  323.          
  324.          The <event> can be
  325.          
  326.              - an ASP event
  327.              - a timer event
  328.              - a OTHERWISE pseudo-event.
  329.          
  330.          A.3.2.1  Single ASP events.
  331.          
  332.          If the <event> is an ASP event then the names for the ASPs are
  333.          those specified in the Declaration Part (the value is specified as
  334.          a reference in the CONSTRAINTS REFERENCE column).
  335.          
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.          Example line for an ASP event:
  348.          
  349.                   I?DELind
  350.          
  351.          This means that a Deliver Indication is received at
  352.          the IUT's SAP I.
  353.          
  354.          A.3.2.2  Single Timer events.
  355.          
  356.          If <event> is a timer event then it is of the form
  357.          
  358.                   <operation> <parameters>
  359.          
  360.          The "start" operation can take one of two forms:
  361.          
  362.               Start <timer type>
  363.               Start (<timer type>,<timer id>)
  364.          
  365.          Where <timer type> is defined in the Declaration Part and has a
  366.          fixed value associated with it defined in terms of TSPs. The <timer
  367.          id> allows a name to be attached to an instance of a timer type.
  368.          
  369.          The other operations are:
  370.          
  371.               Cancel:   cancels a running or suspended timer
  372.               Suspend:  suspends a running timer
  373.               Resume:   resumes a suspended timer
  374.               Timeout:  expiration of a running timer
  375.          
  376.          These operations take one of two forms:
  377.          
  378.               <operation> <timer type>
  379.               <operation> <timer id>
  380.          
  381.          where <operation> denotes the operation. When the timer was started
  382.          using the form "Start <timer type>", the form "<operation> <timer
  383.          type>" must be used; when the timer was started using the form
  384.          "Start <timer id>", the form "<operation> <timer id>" must be used.
  385.          
  386.          Example:
  387.          
  388.              I!Start T/I-timer_1
  389.              
  390.              means that at the IUT's SAP I the T/I-timer_1 (e.g. for a
  391.              transmission time for a UAPDU to be transferred from the tester
  392.              to the IUT's user) is started.
  393.              
  394.              I?Timeout T/I-timer_1
  395.              
  396.              means that at the IUT's SAP I the timeout of the above timer is
  397.              received.
  398.  
  399.          A.3.2.3  Single OTHERWISE events.
  400.          
  401.          If <event> is the OTHERWISE pseudo-event, this indicates an
  402.          unspecified event.
  403.          
  404.          Example:
  405.          
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.              T?OTHERWISE
  413.              
  414.              Means that at the tester's SAP T an unspecified event
  415.              is received.
  416.          
  417.          A.3.2.4  Trees of behaviour
  418.          
  419.          Trees of behaviour combine events in two ways:
  420.          
  421.          - as sequences of events
  422.          - as alternative events
  423.          
  424.          The two combination kinds are distinguished by indented and
  425.          vertical alignment respectively.
  426.          
  427.          Example of a sequence of events:
  428.          
  429.              I!SUBreq
  430.               I?SUBcon
  431.                T?TRNind
  432.              
  433.              This means that first at the SAP I a Submission Request is
  434.              sent, then at the same SAP a Submission Confirmation is
  435.              received, after which a Transfer Indication is received at the
  436.              tester's SAP T.
  437.              
  438.          Example of alternative events:
  439.              
  440.              T?DELind
  441.              T?Timeout I/T-timer
  442.              
  443.              This means that at SAP T either a Deliver Indication is
  444.              received or alternatively the timeout is received there.
  445.          
  446.          To build up a complex behaviour tree, the two kinds of combination
  447.          can be mixed.
  448.          
  449.          Example:
  450.          
  451.  
  452.  
  453.  
  454.  
  455.          
  456.              This means that after sending a Submission Request at I, either
  457.              a Submission Confirmation is received at I, followed by the
  458.              receipt of a Transfer Indication at T, or a Disconnect
  459.              Indication is received at T.
  460.  
  461.          A.3.3  Defaults Library
  462.          
  463.          General default behaviours which are used by several test cases are
  464.          defined in the Defaults Library using the format shown in figure
  465.          A-8/X.403. The name of the default is of the form:
  466.          
  467.          LIB_<name>
  468.          or
  469.          LIB_<name> [X]
  470.          
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.          where X is a place holder which is replaced by an actual SAP when
  483.          applying the default element in a particular Test Case.
  484.          
  485.          Note:
  486.          
  487.          Where particular default behaviour applies to a single test case
  488.          only the behaviour table is associated with that test case and the
  489.          identifier is not prefixed with "LIB_".
  490.          
  491.                                                                     
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.          
  506.          Figure A-8/X.403  Default Behaviour.
  507.          
  508.          
  509.          A.3.4  Test Step Library
  510.          
  511.          Where a sequence of test steps is of use in several test cases they
  512.          can be included in the Test Step Library and given a name of the
  513.          form:
  514.          
  515.          LIB_<name>
  516.          
  517.          Note:
  518.          
  519.          Where a test step applies to a single test case the behaviour table
  520.          is associated with that test case and the identifier is not
  521.          prefixed with "LIB_".
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.                                                                     
  538.          
  539.          Figure A-9/X.403  Test Step Behaviour.
  540.          
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.          A.3.5  Test Case
  548.          
  549.          Each test case in the main body of the test suite is described in
  550.          terms of three headings (a) - (c), and a behaviour tree (d)
  551.          
  552.          (a) Test Reference and Test Identifier
  553.             
  554.              These elements give a unique reference and identifier for each
  555.              test case and are described fully in section A.5.
  556.          
  557.          (b) Summary
  558.             
  559.              A brief overview of the purpose of the test is provided.
  560.          
  561.          (c) Test Description (optional)
  562.             
  563.              This provides an informal description of the actions and events
  564.              that should take place during the test and an informal verdict
  565.              criteria.
  566.          
  567.          (d) Behaviour Tree
  568.             
  569.              Dynamic behaviour is described using the tree notation defined
  570.              in section A.3.2.
  571.                                                                     
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.          
  585.          Figure A-10/X.403  Test Case Behaviour.
  586.          
  587.          
  588.          Note 1: In this field all Default Library Identifiers used are
  589.                  inserted. Where necessary, the SAP at which they are applied
  590.                  is also identified. If for example the field contains the
  591.                  entry:
  592.                 
  593.                         LIB_unexpected [T]
  594.                 
  595.                  it means that the subtree associated with this Default
  596.                  Behaviour is considered to be associated with the SAP T.
  597.                 
  598.          Note 2: Test Step Library behaviour is included in the behaviour
  599.                  tree using the following notation:
  600.          
  601.                         + <Test Step Library Identifier>
  602.                 
  603.          Note 3: The behaviour tree of every Test Case provides the
  604.                  verdicts pass, fail, and where appropriate inconclusive.
  605.                 
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.          Note 4: When using Default Library elements it is possible
  618.                  that some of the verdict alternatives are "hidden" in the
  619.                  Default Library element.
  620.          
  621.          A.4  Constraints Part
  622.          
  623.          The Constraints Part of a Test Suite specifies the values and their
  624.          encoding of all instances of ASPs, Test PDUs, Base PDUs and Library
  625.          Components. The Constraints Parts is divided into the following
  626.          sections:
  627.          
  628.           -   Introduction to Constraints Part
  629.           -   ASP Constraints
  630.           -   Test PDU Constraints
  631.           -   Base PDU Constraints
  632.           -   Components Library
  633.          
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.                           
  655.          
  656.          Figure A-11/X.403 The structure of the Constraints Part.
  657.          
  658.          A.4.1  ASP Constraints
  659.          
  660.          Values of ASPs are defined as specific instances of a generic ASP.
  661.          
  662.          A.4.1.1  Specification of a "Generic" ASP
  663.          
  664.          A generic ASP is defined using the format shown in Figure A-12/X.403.
  665.          
  666.                                                                     
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.          
  690.          Figure A-12/X.403  Generic ASP specification.
  691.          
  692.          The "FIELDS" column is used to list all the parameters of the ASP.
  693.          
  694.          The "VALUE or REFERENCE" column is used to specify a value for each
  695.          parameter and this can be done in four ways:
  696.          
  697.          (a) As a reference which can be a TSP name or a library component
  698.              name.
  699.          
  700.          (b) As an explicit value.
  701.          
  702.          (c) As "-" to indicate that this parameter may be omitted in
  703.              specific instances of this ASP.
  704.          
  705.          (d) As "?" to indicate that for "request" ASP's this parameter must
  706.              have a value defined in a specific instance if it is a component
  707.              of interest.
  708.          
  709.          A.4.1.2  Specification of ASP Instances
  710.          
  711.          Specific values of ASPs are defined using the tabular format shown
  712.          in Figure A-13/X.403.
  713.          
  714.                                                                     
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.          
  729.          Figure A-13/X.403  Specific ASP value.
  730.          
  731.          
  732.          The "INSTANCE NAME" column is used to identify specific instances
  733.          of the ASP used in the test suite.
  734.          
  735.          The "MODIFIED PARAMETER" column identifies, for "request" ASP's
  736.          those parameters whose values are to be modified from the generic
  737.          ASP specification, and for "notification" ASP's those parameters
  738.          whose values are to be checked.
  739.          
  740.          The "VALUE or REFERENCE" column can contain either specific values
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.          or references to library components ASPs or test PDUs.
  753.          
  754.          A.4.2  Specifying PDU values
  755.          
  756.          The MHS test suite contains a large number of test PDU values. Each
  757.          PDU is defined in terms of modifications to one of the small number
  758.          of "base" PDUs.
  759.          
  760.          For convenience commonly used PDU components are defined in a
  761.          library and are referenced by test PDUs and base PDUs.
  762.          
  763.          A.4.3  Base PDUs
  764.          
  765.          A.4.3.1  Base PDU specification
  766.          
  767.          Base PDUs are not themselves used as test PDUs but they serve as a
  768.          basis from which to derive the test PDUs. Usually only a few Base
  769.          PDUs need to be specified.
  770.          
  771.          The name of a Base PDU is of the form:
  772.          
  773.                    BASE_<PDUtypename>_<number>
  774.          
  775.          An example of a Base PDU is shown below.
  776.          
  777.          Example:
  778.          
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.                                                                      
  798.          
  799.          The value or value reference of each element of the structure is
  800.          specified within square brackets ("[" and "]") under the VALUE or
  801.          REFERENCE heading.
  802.  
  803.          When specifying the encoding of a PDU for encoding/decoding
  804.          tests,two additional columns are used to specify the ID Code [ID]
  805.          and Length Indicator [LI] of each element of the PDU. The format
  806.          for doing this is shown in the example below.
  807.          
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.          The values of ID and LI can be specified explicitly to allow
  831.          invalid and various forms of valid codings to be defined. The
  832.          mnemonic "LI" is used to indicate that any valid encoding of length
  833.          is allowed.
  834.          
  835.          A.4.3.2  Identifying the components to be modified
  836.          
  837.          A component which is to be replaced in a PDU is identified by a
  838.          path through the declaration of the PDU. The path is written as a
  839.          list of elements, each separated from the next by a ".". The
  840.          elements in the list can be labels which appear in a BASE PDU,
  841.          components which appear in the left-hand side of a labeled
  842.          declaration, or components which appear in the left-hand side of
  843.          the expansion of a library reference in the right-hand side of a
  844.          declaration.
  845.          
  846.          For example, consider the following definitions:
  847.          
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.          
  864.          In order to reference "a", the path would be instance_1.a.
  865.          In order to reference "e", the path would be instance_1.b.d.e.
  866.  
  867.          A.4.4  Test PDUs
  868.          
  869.          Test PDUs are defined in terms of operations on Base PDU's. These
  870.          operations refer to Library Components, TSPs or specific values.
  871.          
  872.          There are two kinds of test PDU:
  873.          
  874.           -  PDUs sent by the tester (IUT as recipient)
  875.          
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.              By convention the names of these PDUs are of the form
  888.             
  889.                    <PDU name>_x_<number>
  890.             
  891.              where x is the number of the base PDU from which the test PDU is
  892.              derived.
  893.             
  894.           -  PDUs received by the tester (IUT as originator)
  895.             
  896.              By convention the names of these PDUs are of the form
  897.             
  898.                    <PDU name>_0_<number>
  899.             
  900.              where "0" indicates that these test PDUs are not derived from a
  901.              base PDU.
  902.          
  903.          A.4.4.1  Test PDUs sent by the tester
  904.          
  905.          A test PDU sent by the tester to the IUT is normally constructed
  906.          from a Base PDU by means of the REPLACE operation.
  907.          
  908.          The specification has the form:
  909.          
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.          For the conventions of value assignments see section A.4.6.
  922.          
  923.          Example:
  924.          
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.                                                                     
  937.          
  938.          
  939.          To construct invalid components in test PDUs to be sent by the
  940.          tester, the abstract REDEFINE operation is sometimes used. It is
  941.          used together with the REPLACE operation in the following form:
  942.          
  943.          
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954.  
  955.  
  956.  
  957.  
  958.  
  959.  
  960.  
  961.          
  962.          The scope of the newly defined type is restricted to the PDU
  963.          definition containing the REDEFINE operation.
  964.          
  965.          Note that if the <value> is a reference to an element defined
  966.          elsewhere (i.e. a TSP or a Library Component), then the new type
  967.          definition does not affect the referenced element itself but only
  968.          its usage in the actual PDU.
  969.  
  970.          Example:
  971.          
  972.                                                                     
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.                                                                     
  989.          
  990.          The error to be constructed here is the wrong tag of the ORName
  991.          type (the correct tag would be [APPLICATION 0]). The scope of the
  992.          erroneous type-definition constructed by "REDEFINE" is restricted
  993.          to all occurrences of ORName in the definition of IM_UAPDU_1_3.
  994.          This means that L_ORDescriptor_1 is used here with the modified
  995.          ORName type, whereas the usage of this library component in other
  996.          PDUs or components remains unaltered.
  997.          
  998.          A.4.4.2  Test PDUs received by the tester
  999.          
  1000.          For received PDUs normally only a portion of the PDU relates to the
  1001.          purpose of the test.
  1002.          
  1003.          A component of interest is identified and its value assigned using
  1004.          the techniques described in A.4.3.
  1005.          
  1006.          The specification scheme has the following form:
  1007.          
  1008.  
  1009.  
  1010.  
  1011.  
  1012.  
  1013.  
  1014.  
  1015.  
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021.  
  1022.  
  1023.  
  1024.  
  1025.  
  1026.  
  1027.          
  1028.                                                                         
  1029.  
  1030.  
  1031.  
  1032.          
  1033.          Example:
  1034.          
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.                                                                         
  1047.          
  1048.         
  1049.          A.4.5  Component Library
  1050.          
  1051.          Components of PDUs are defined in the library and are referenced in
  1052.          Base PDU specifications, Test PDU specifications and by other
  1053.          library components.
  1054.          
  1055.          The name of a Library Component is of the form:
  1056.          
  1057.                    L_<ASN.1 type name>_<number>
  1058.          
  1059.          and is specified using the techniques described in A.4.3.
  1060.          
  1061.          Example:
  1062.          
  1063.                                                                      
  1064.  
  1065.  
  1066.  
  1067.  
  1068.  
  1069.  
  1070.  
  1071.  
  1072.  
  1073.  
  1074.  
  1075.  
  1076.  
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.          A.4.6  Value Conventions
  1093.          
  1094.          The following conventions are used when defining values or value
  1095.          references for PDU components.
  1096.          Value references identify components defined either within the
  1097.          Component Library or within the Test Suite Parameters section.
  1098.          CharacterString Values can specified within double-quotes (eg
  1099.          "abc"); Bit String Values are specified within single-quotes (eg
  1100.          '0A'H or '0001'B; hexadecimal or binary notation); Integer Values
  1101.          are specified as numeric characters (eg 2); sets and sequences of
  1102.          values are specified within curly brackets separated by comma (eg
  1103.          {"abc",'0A'H}).
  1104.          
  1105.          For PDU's sent by the tester :
  1106.          
  1107.            [ ? ]  indicates that the value has no influence on the test and
  1108.                   may be anything that is legal according to the relevant
  1109.                   service or protocol standard.
  1110.          
  1111.            [ - ]  indicates that the parameter shall be absent.
  1112.          
  1113.            [ * ]  indicates that the value is to be inserted by the tester
  1114.                   before test execution.
  1115.          
  1116.          For PDU's received by the tester :
  1117.          
  1118.            [ ? ]  indicates that the tester need make no verification of the
  1119.                   value of the parameter .
  1120.          
  1121.            [ - ]  indicates that the tester shall check that the parameter
  1122.                   is absent.
  1123.          
  1124.          Note that the "?" and "-" symbols in value assignments of PDU
  1125.          components have got other meanings than "?" and "-" in generic ASP
  1126.          schedules.
  1127.  
  1128.          A.5  Test Case Identification
  1129.          
  1130.          Test cases are completely identified using four components:
  1131.          
  1132.           -  a test group identifier.
  1133.           -  a subgroup identifier.
  1134.           -  a validity identifier.
  1135.           -  a test number.
  1136.          
  1137.          These four components are specified in two equivalent ways:
  1138.          
  1139.           -  As a Test Reference where the four components are textual and
  1140.              descriptive.
  1141.             
  1142.              Example:
  1143.                       OriginalEncodedInfoTypeIndication/Recipient/Valid/2
  1144.          
  1145.           -  As a Test Identifier where the four components are numeric and
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.              concise.
  1158.  
  1159.             Example:
  1160.                       307.2.1.2
  1161.          A.5.1  IPMS(P2) and MTS(P1) identification
  1162.          
  1163.          A.5.1.1  Test Groups
  1164.          
  1165.          Number ranges have been allocated for the test groups as shown
  1166.          below:
  1167.          
  1168.              Initial Tests                       001 - 099
  1169.              X.409 Tests                         100 - 199
  1170.              Protocol Elements Tests             200 - 299
  1171.              (for frequently occurring Elements)
  1172.              X.400 Service Elements Tests        300 - 399
  1173.              Additional Tests                    400 - 499
  1174.          
  1175.          A.5.1.2  Subgroups
  1176.          
  1177.          Numeric identifiers have been allocated to the test subgroups as
  1178.          shown below:
  1179.          
  1180.              Originator           1
  1181.              Recipient            2
  1182.              encode               1
  1183.              decode               2
  1184.              Relay                3
  1185.              Relaying-Recipient   4
  1186.              Relaying-Originator  5
  1187.          
  1188.          A.5.1.3  Validity identifiers
  1189.          
  1190.          Test cases which exercise valid behaviour are distinguished from
  1191.          those which exercise the IUT's reaction to invalid behaviour using
  1192.          the numeric identifiers shown below:
  1193.          
  1194.              Valid         1
  1195.              Invalid       2
  1196.          
  1197.          A.5.1.4  Test case numbers
  1198.          
  1199.          Test cases for a particular group/subgroup/validity are numbered
  1200.          sequentially.
  1201.          
  1202.          A.5.2  RTS Identification
  1203.          
  1204.          A.5.2.1  Test Groups
  1205.          
  1206.          Number ranges have been allocated for the test groups as shown
  1207.          below:
  1208.          
  1209.              Association Establishment   1
  1210.              Association Release         2
  1211.              Data Transfer               3
  1212.              Association Recovery        4
  1213.              X.409 Tests                 5
  1214.          
  1215.          A.5.2.2  Subgroups
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.          
  1223.          Numeric identifiers have been allocated to the RTS subgroups as
  1224.          shown below:
  1225.          
  1226.              Initiator     1
  1227.              Responder     2
  1228.              Sender        1
  1229.              Receiver      2
  1230.          
  1231.          A.5.2.3  Validity identifiers
  1232.          
  1233.          Test cases which exercise valid behaviour are distinguished from
  1234.          those which exercise the IUT's reaction to invalid and inopportune
  1235.          behaviour using the numeric identifiers shown below:
  1236.          
  1237.              Valid         1
  1238.              Invalid       2
  1239.              Inopportune   3
  1240.          
  1241.          A.6  Cross Referencing
  1242.          
  1243.          A.6.1  Cross Reference Numbering
  1244.          
  1245.          The MTS(P1) and IPMS(P2) test suites contain a cross referencing
  1246.          system for the ASPs, test PDUs and library components. The cross
  1247.          referencing appears in the left and right margins of the test suite
  1248.          as shown in Figure A-14/X.403.
  1249.          
  1250.                                       
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.          
  1262.          Figure A-14/X.403  Cross referencing.
  1263.          
  1264.          Numbers in the left hand margin of the test suite are in sequential
  1265.          order and are "place identifiers". They occur whenever an ASP, test
  1266.          PDU or library component occurs in the test suite.
  1267.          
  1268.          Whenever an ASP, test PDU or library component occurs, numbers are
  1269.          also placed in the right hand margin. These numbers are forward and
  1270.          backward references to the place identifiers of the other
  1271.          occurrences of the ASP, test PDU or library component.
  1272.          
  1273.          Where a forward or backward reference can not be found then a dot
  1274.          (".") is printed in the right hand margin. This should not occur in
  1275.          fully defined test suites.
  1276.          
  1277.          Where a line in the test suite contains more than one ASP, test PDU
  1278.          or library component, the cross references for each item in the
  1279.          line are separated by vertical bars (" ") in the right hand margin
  1280.          as shown in Figure A-15/X.403.
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290.  
  1291.  
  1292.          
  1293.  
  1294.  
  1295.  
  1296.  
  1297.  
  1298.          
  1299.          Figure A-15/X.403  Multiple cross references.
  1300.  
  1301.          
  1302.          A.6.2  Cross Reference Listing
  1303.          
  1304.          At the end of MTS(P1) and IPMS(P2) test suites there is a separate
  1305.          cross reference listing of all the ASPs, test PDUs and library
  1306.          components together with the place identifiers of all their
  1307.          occurrences in the test suite.
  1308.          
  1309.          Example:
  1310.                              :
  1311.                              :
  1312.                       IM_UAPDU_1_14   586 1467
  1313.                       IM_UAPDU_1_15   587 1470
  1314.                              :
  1315.                              :
  1316.          
  1317.          The numbers on the right side indicate the places where the item
  1318.          occurs in the test suite.
  1319.          
  1320.          Annex B  IPMS(P2) PICS Proformas
  1321.          
  1322.          B.1  General
  1323.          
  1324.          As a prerequisite to conformance testing the supplier of an
  1325.          IPMS(P2) implementation must provide a Protocol Implementation
  1326.          Conformance Statement (PICS).
  1327.          
  1328.          The proforma IPMS(P2) PICS contained in this Annex specifies the
  1329.          information to be supplied.
  1330.          
  1331.          This information is needed for test case selection. Suppliers
  1332.          should note that tests will be performed to check that services
  1333.          shown as not supported are in fact not present rather than
  1334.          improperly implemented.
  1335.          
  1336.          The IPMS(P2) PICS is in two parts:
  1337.          
  1338.           -  a part requesting information concerning the support of service
  1339.              elements,
  1340.          
  1341.           -  a part requesting information concerning the support of
  1342.              protocol elements.
  1343.          
  1344.          Information on service element support is requested in tabular form
  1345.          where, for each service element,
  1346.          
  1347.           -  the status of the service element is indicated as mandatory
  1348.              (M), optional (O) or not applicable (-) in columns labelled
  1349.              "STD",
  1350.          
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357.           -  the actual support of the service element by the implementation
  1358.              on origination and reception is indicated by the supplier in
  1359.              columns labelled "IMP".
  1360.          
  1361.          Information on protocol element support is requested in tabular
  1362.          form where, for each protocol element,
  1363.          
  1364.           -  the status of the protocol element on origination and reception
  1365.              is indicated as mandatory (M) or optional (O) in columns
  1366.              labelled "STD",
  1367.          
  1368.           -  any implementation constraints are indicated in the column
  1369.              labelled "CONST STD" where constraints are interpreted as a
  1370.              minimum for reception and a maximum for origination,
  1371.          
  1372.           -  the actual support of the protocol element by the
  1373.              implementation on origination and on reception is indicated by
  1374.              the supplier in the column labelled "STATUS IMP",
  1375.          
  1376.           -  the actual constraints of the implementation on origination and
  1377.              on reception is indicated by the supplier in the columns
  1378.              labelled "CONST IMP".
  1379.          
  1380.             Constraints may be expressed as a length or size (octets,
  1381.             bits,...), a value (32k-1) or a number of occurrences (4)
  1382.             depending on the element being constrained.
  1383.          
  1384.          B.2  IPMS(P2) PICS Service Elements Proforma
  1385.          
  1386.          The requirements of the X.400 Recommendations are shown in the STD
  1387.          columns of the proforma using the following keys:
  1388.          
  1389.             M  :  Mandatory element (X.401 Basic or Essential Optional)
  1390.             O  :  Optional element  (X.401 Additional Optional)
  1391.             -  :  Not applicable service element
  1392.          
  1393.          Suppliers of an implementation should use the IMP columns in the
  1394.          proforma to specify information concerning the support of service
  1395.          elements. For convenience it is suggested that suppliers need only
  1396.          indicate with an "X" those service elements that are not supported.
  1397.          
  1398.          
  1399.          Table: B-1/X.403  IPMS(P2) Service Elements Proforma  (Part 1 of 2)
  1400.          
  1401.                                                                       
  1402.  
  1403.  
  1404.  
  1405.  
  1406.  
  1407.  
  1408.  
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421.  
  1422.  
  1423.  
  1424.  
  1425.  
  1426.  
  1427.  
  1428.  
  1429.  
  1430.  
  1431.  
  1432.  
  1433.  
  1434.  
  1435.  
  1436.  
  1437.  
  1438.  
  1439.  
  1440.  
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.          Table: B-1/X.403  IPMS(P2) Service Elements Proforma  (Part 2 of 2)
  1449.          
  1450.                                                                       
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458.  
  1459.  
  1460.  
  1461.  
  1462.  
  1463.  
  1464.  
  1465.  
  1466.  
  1467.  
  1468.  
  1469.  
  1470.  
  1471.  
  1472.  
  1473.  
  1474.  
  1475.  
  1476.  
  1477.  
  1478.  
  1479.  
  1480.  
  1481.  
  1482.  
  1483.  
  1484.  
  1485.  
  1486.  
  1487.  
  1488.  
  1489.  
  1490.  
  1491.  
  1492.  
  1493.  
  1494.  
  1495.  
  1496.  
  1497.  
  1498.  
  1499.  
  1500.                                                                       
  1501.  
  1502.          B.3  IPMS(P2) PICS Protocol Elements Proformas
  1503.          
  1504.          The requirements of the X.400 Recommendations are shown in the
  1505.          STATUS STD columns of the proformas in Tables B-2/X.403 to
  1506.          B-4/X.403 using the following keys:
  1507.          
  1508.             M  :  Mandatory element (X.401 Basic or Essential Optional)
  1509.             O  :  Optional element  (X.401 Additional Optional)
  1510.          
  1511.          Protocol elements which correspond directly to service elements are
  1512.          indicated as mandatory if their corresponding service elements are
  1513.          shown in X.401 (1984) as Basic or Essential Optional, and as
  1514.          optional if their corresponding service elements are shown in X.401
  1515.          (1984) as Additional Optional. Other protocol elements are
  1516.          indicated as mandatory or optional according to their designation
  1517.          in the UAPDU definitions in X.420 (1984).
  1518.          
  1519.          The pragmatic constraints of the X.400 Implementor's Guide are
  1520.          shown in the CONST STD columns of the proformas in Tables B-2/X.403
  1521.          to B-4/X.403.
  1522.          
  1523.          Suppliers of an implementation should use:
  1524.          
  1525.           -  the STATUS IMP columns in each proforma to specify information
  1526.              concerning the support of protocol elements. For convenience it
  1527.              is suggested that suppliers need only indicate with an "X" those
  1528.              protocol elements that are not supported.
  1529.          
  1530.           -  the CONST IMP columns in each proforma to specify the actual
  1531.              constraints of the implementation.
  1532.  
  1533.  
  1534.  
  1535.          Table: B-2/X.403  ORDescriptor proforma.
  1536.          
  1537.  
  1538.  
  1539.  
  1540.  
  1541.  
  1542.  
  1543.  
  1544.  
  1545.  
  1546.  
  1547.  
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570.  
  1571.  
  1572.  
  1573.  
  1574.  
  1575.  
  1576.  
  1577.  
  1578.  
  1579.  
  1580.  
  1581.  
  1582.          
  1583.          Table: B-3/X.403  IM-UAPDU proforma  (part 1 of 3)
  1584.          
  1585.  
  1586.  
  1587.  
  1588.  
  1589.  
  1590.  
  1591.  
  1592.  
  1593.  
  1594.  
  1595.  
  1596.  
  1597.  
  1598.  
  1599.  
  1600.  
  1601.  
  1602.  
  1603.  
  1604.  
  1605.  
  1606.  
  1607.  
  1608.  
  1609.  
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626.  
  1627.  
  1628.  
  1629.  
  1630.  
  1631.  
  1632.  
  1633.  
  1634.  
  1635.  
  1636.  
  1637.  
  1638.  
  1639.  
  1640.  
  1641.  
  1642.  
  1643.  
  1644.  
  1645.          
  1646.          Table: B-3/X.403  IM-UAPDU proforma  (part 2 of 3)
  1647.          
  1648.                                                                             
  1649.  
  1650.  
  1651.  
  1652.  
  1653.  
  1654.  
  1655.  
  1656.  
  1657.  
  1658.  
  1659.  
  1660.  
  1661.  
  1662.  
  1663.  
  1664.  
  1665.  
  1666.  
  1667.  
  1668.  
  1669.  
  1670.  
  1671.  
  1672.  
  1673.  
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682.  
  1683.  
  1684.  
  1685.  
  1686.  
  1687.  
  1688.  
  1689.  
  1690.  
  1691.  
  1692.  
  1693.  
  1694.  
  1695.  
  1696.  
  1697.  
  1698.  
  1699.  
  1700.  
  1701.  
  1702.  
  1703.  
  1704.  
  1705.  
  1706.  
  1707.  
  1708.  
  1709.          
  1710.          Table: B-3/X.403  IM-UAPDU proforma  (part 3 of 3)
  1711.          
  1712.                                                                             
  1713.  
  1714.  
  1715.  
  1716.  
  1717.  
  1718.  
  1719.  
  1720.  
  1721.  
  1722.  
  1723.  
  1724.  
  1725.  
  1726.  
  1727.  
  1728.  
  1729.  
  1730.  
  1731.  
  1732.  
  1733.          
  1734.          Table: B-4/X.403  SR-UAPDU proforma
  1735.          
  1736.  
  1737.  
  1738.  
  1739.  
  1740.  
  1741.  
  1742.  
  1743.  
  1744.  
  1745.  
  1746.  
  1747.  
  1748.  
  1749.  
  1750.  
  1751.  
  1752.  
  1753.  
  1754.  
  1755.  
  1756.  
  1757.  
  1758.  
  1759.  
  1760.  
  1761.  
  1762.  
  1763.  
  1764.  
  1765.  
  1766.  
  1767.  
  1768.  
  1769.  
  1770.  
  1771.  
  1772.  
  1773.  
  1774.  
  1775.